The IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks. IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session. As the number of basic applications, and the media which it is possible to combine, increases, so will the number of services offered to the end users, giving rise to a new generation of personalised, rich multimedia communication services. The IMS is defined in the 3GPP Specification 23.228.
The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly.
FIG. 1 illustrates schematically how the IMS 3 fits into the mobile network architecture in the case of a GPRS/PS access network. As shown in FIG. 1 control of communications occurs at three layers (or planes). The lowest layer is the Connectivity Layer 1, also referred to as the bearer, or traffic plane and through which signals are directed to/from user terminals accessing the network. The GPRS network includes various GPRS Support Nodes (GSNs) 2a, 2b. A gateway GPRS support node (GGSN) 2a acts as an interface between the GPRS backbone network and other networks (radio network and the IMS network). A Serving GPRS Support Node (SGSN) 2b keeps track of the location of an individual Mobile Terminal and performs security functions and access control. Access to the IMS 3 by IMS subscribers is performed through an IP-Connectivity Access Network (IP-CAN). In FIG. 1 the IP-CAN is a GPRS network including entities linking the user equipment to the IMS 3 via the connectivity layer 1.
The IMS 3 includes a core network 3a, which operates over the middle, Control Layer 4 and the Connectivity Layer 1, and a Service Network 3b. The IMS core network 3a includes nodes that send/receive signals to/from the GPRS network via the GGSN 2a at the Connectivity Layer 1 and network nodes that include Call/Session Control Functions (CSCFs) 5. The CSCFs 5 include Serving CSCFs (S-CSCF) and Proxy CSCFs (P-CSCF), which operate as SIP proxies within the IMS in the middle, Control Layer.
At the top is the Application Layer 6, which includes the IMS service network 3b. Application Servers (ASs) 7 are provided for implementing IMS service functionality. Application Servers 7 provide services to end-users on a session-by-session basis, and may be connected as an end-point to a single user, or “linked in” to a session between two or more users. Certain Application Servers 7 will perform actions dependent upon subscriber identities (either the called or calling subscriber, whichever is “owned” by the network controlling the Application Server 7).
These session-based applications enable one or more users to participate in interactive user sessions such as video, voice, chat, gaming and virtual reality sessions. The IMS architecture also makes it possible to deploy peer-to-peer applications where two or more users exchange data during a SIP session. Examples of such peer-to-peer applications include Multimedia Telephony (MMTel), Push to Talk over Cellular (PoC), streaming, real-time video sharing, file sharing, gaming etc. The transport connection(s) is (are) negotiated dynamically by means of the SIP/SDP protocol exchange between the two end points (user terminals).
However, in order to support such peer-to-peer applications, there are two basic requirements: (i) a mechanism is needed to selectively control the SIP signal flows associated with the IMS session(s) of a subscriber; and (ii) a functionality is needed to control the IP flows through the dynamically negotiated transport connections in order to apply an effective charging for usage of services. One important aspect concerns the resources required for the session, which will impact on the Quality of Service (QoS) provided for the session (e.g. the data rate at which data is transferred between the end users). In the discussion below the term QoS is used to refer to those parameters of a requested or on-going session that determine the Quality of the Service experienced by the end user. The principal bearer resource affecting QoS is the available bandwidth for the session.
The 3GPP has recognised these needs and has defined a Policy and Charging Control (PCC) Architecture (see 3GPP Technical Specification 23.203). FIG. 2 presents the basic outline of the PCC architecture. The Application Function (AF) 16 is an element offering applications that require dynamic policy and/or charging control of traffic plane resources. Although the application services are initiated and service characteristics are negotiated at the Application Layer 6 (e.g. by an Application Server 7—see FIG. 1), a CSCF 5 (the P-CSCF) plays the role of the AF 16 at the SIP signalling plane (Control Layer 4). A Policy and Charging Enforcement Function (PCEF) 12 in the Connectivity Layer 1 monitors service data flow and enforces network policy. The PCEF 12 also applies charging based on the monitored data flow and the charging policy applied. This information is provided to an Online Charging System 13 over the Gy interface. As shown in FIG. 2, the PCEF 12 is contained within the access gateway node. Within a GPRS access network, the PCEF 12 is located in the GGSN 2a. Within the Systems Architecture Evolution defined in 3GPP Release 8, the PCEF is located in the Public Data Network (PDN) gateway.
A Policy and Charging Rules Function (PCRF) 14 resides in between the AF 16 and the PCEF 12. The PCRF 14 is the entity that controls charging based on the monitored data flow. The PCRF 14 obtains rules relating to the charging policy to be applied for particular subscribers over the Sp interface from a Subscription Profile Repository (SPR) 18, which includes a database of subscriber information. The PCRF 14 installs these PCC rules at the PCEF 12 over the Gx interface. These ensure that only authorized media flows associated with the requested services are allowed. In addition, the PCC rules installed at the PCEF 12 ensure that the right bandwidth, charging and priority are applied through the right bearer.
Once session characteristics are negotiated between the communication peers and the session characteristics are authorized within the IMS Core Network 3a, the AF 16 provides an authorization of bearer resources over the Rx interface to the PCRF 14 so that the corresponding resource reservation can be authorized at the Connectivity Layer 1. The PCC architecture is used to control the bearer resources and thus guarantee that services are delivered with the right quality—i.e. the quality required for the particular services provided, but also in accordance with the user's access subscription and access operator policies. IP-CAN operators normally apply bandwidth limits in terms of the concurrent bandwidth available to their users at a given moment in time (e.g. 200 kbps bit pipe). Access operators may also limit the bandwidth available for certain access technologies (e.g. for UTRAN access, the maximum bandwidth allowed is 80 kbps). Access network operators may also limit the number of concurrent bearers/services available to their users. When these limitations are reached and the quality for the service cannot be guaranteed, the PCC architecture will reject the bearer resources for the service. In this PCC configuration, the PCRF will inform the AF of the reason for the rejection so that it can take appropriate action (e.g. reject the session, re-negotiate the session, etc.). In scenarios where an AF is not present (Rx is not used), the PCRF will downgrade or even reject a bearer establishment or modification attempt from the UE.
However, these limitations are controlled and managed by the access network (IP-CAN) operator, meaning that the UEs and clients are not aware of them. The UEs in use today include many that support advanced capabilities such as the use of the most up-to-date codecs. In the future UEs will be able to support still more advanced capabilities. These UEs will try to initiate services making use of the highest capabilities they support. For example, an IMS client's UE will normally attempt to initiate a session by offering all the codecs it supports (unless manually configured otherwise), ignoring any bandwidth limitation set by the access operator. Similarly, users may also try to run a number of services on their terminals concurrently. For example, a user may want to download e-mail and transfer files using File Transfer Protocol (FTP) at the same time as having an MMTel video call. In this case, the UE may attempt to establish multiple bearers. The number of bearers that can be active simultaneously is, on the one hand limited by the UE manufacturer's implementation (i.e. the terminal is capable of handling a maximum number of concurrent bearers). On the other hand, there may be a limit imposed by the network on the number of bearers a user is allowed to establish, regardless of the capabilities of the terminal.
In summary—network-based mechanisms are used to control the usage of resources for a session, but UEs may try to maintain multiple concurrent services making use of their most advanced capabilities. This will frequently result in additional control signalling. At the application level a round of Request and Reject control messages may be followed by a re-attempt of the original request using different characteristics (e.g. downgrading of QoS with a request for lower bandwidth, less demanding codecs or restricting use of particular media-types) to try and establish a session without exceeding the access operator's established limits. At the bearer level there will either be a round of Request/Reject control signalling messages or a round of Request/Response messages (accepting a downgraded QoS) potentially followed by a bearer termination if the QoS downgrade is not acceptable for the service delivery.
The present invention has been conceived with the foregoing in mind.